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The History of Language Processor Technology in IBM 


r, , • , „ of language processor technology in IBM is described in this paper. Most of the paper is devoted to compiler 
, lol- interpreters assemblers . and macro systems are discussed briefly. The emphasis is on saenttfic contnbu- 
^jons^nd^tech'nohgical advances from a historical perspective. The synergistic relationship betsveen theory 
is a subtheme. 


Introduction 

In 1953 IBM introduced an early "automatic-program- 
ming” system: Speedcode for the IBM 701 computer. 
The goal of the system was to [1] • • lessen the 

enormous burdens of the programmer by providing a 
larger and more convenient instruction repertoire than a 
given machine provides." In the same paper John Backus 
and Harlan Herrick go on to state: "There are two 
principal methods by which automatic-programming sys- 
tems make these nonmachine operations available to the 
programmer: the interpretive method and the compiling 
method." In the almost 30 years that have intervened 
since these observations were first made, methods for 
solving "the programming problem" have become more 
diverse and sophisticated, but the basic problem remains. 
Language processors-compilers, interpreters, macro 
systems, and assemblers-are still the principal methods 
used. In this paper we trace the history of IBM s contri- 
butions to the techniques used in today’s language pro- 
cessors. The paper concentrates on IBM's scientific and 
technological contributions, covering only widely used, 
general purpose techniques or those of particular scien- 
tific or historical interest. 

The development of language processor technology, 
particularly compiler technology, is intimately inter- 
twined with the development of computer science. Ad 
hoc solutions to pragmatic problems have continued to be 
replaced by elegant algorithms. Large, amorphous, seem- 
ingly intractable problems have been divided and con- 
quered. The best example of this is in the area of parsing. 
Early solutions to the problem of decomposing a state- 


ment into its component parts were both elaborate and 
language-specific. The problem became the subject of 
numerous theoretical investigations and spawned a sub- 
field of computer science: formal language theory. To- 
day, elegant, language-independent parsing systems exist 
and are a common component of production compilers. 
The synergistic relationship between theory and practice 
continues to play a vital role in the development of 
language processor technology. This relationship is a 
subtheme of the paper: Particular attention is paid to 
tracing the origins and evolution of various techniques. 


The history of language processors in IBM divides 
quite naturally into five periods, generally delineated by 
the introduction of significant new products. The first 
period, covered in the section on “Early history,” starts 
with the introduction of the IBM 701 in 1952. In 1954 
work began on fortran I— a language and system which 
established the foundations of compiler technology, set 
standards rarely achieved today, and, as a result, dramat- 
ically accelerated compiler development. The second 
section is devoted entirely to the fortran I compiler. The 
period from the introduction of the fortran I compiler to 
the introduction of the System/360-“The late fifties and 
early sixties”— is the subject of the third section. The 
mid- and late sixties" is followed by “Recent history: the 
seventies,” concluding the main presentation. The sum- 
mary recapitulates the central ideas which have led to the 
elegant solutions we have today. The paper concludes 
with some personal observations and predictions. 
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Early history 

• Historical context 

In 1952 IBM introduced its first production-line electronic 
digital computer and with it IBM's first language proces- 
sor— the NR9003 symbolic programming system. Some 
surprisingly advanced techniques already existed. 

Libraries of subroutines and the use of combining 
routines (“compilers") had been proposed by Goldstine 
and von Neumann [2] and existed in several systems. A 
book on programming [3] published in 1951 describes a 
system having open and closed subroutines and preset 
and program parameters. Preset parameters were incor- 
porated into the subroutine when it was read into the 
system and remained fixed for all executions: program 
parameters were passed with the call to the subroutine. 
The programmer’s task was to write a combining routine 
which would take the proper subroutines from tape and 
modify them appropriately. The motivation for these 
facilities was to reduce programming time: they were the 
first step in the direction of using a computer to help 
prepare programs for itself. 

A second step was the use of "a programmer’s lan- 
guage" instead of the machine’s language. This evolved 
quite slowly. The use of symbols for machine operations 
came first, then relative numbers to which fixed reloca- 
tion values could be added became common for instruc- 
tion and data locations. However, by 1952 a “floating- 
address" notation had been developed by Wilkes [4, 5]: 
Any word or group of words could be designated by a 
letter or letter-number combination. The assembler for 
this language [5] had what was to become the classic 
structure. Two passes were made over the program: the 
first to assign a location to each word, and the second to 
fill in the correct values for the floating addresses. 

Wilkes [4] also proposed “synthetic orders" which 
expanded into several parameterizable floating-address 
instructions. The expander acted as a preprocessor to the 
assembler, and its output could be saved to avoid unnec- 
essary re-expansion on subsequent assemblies. Modem 
macro preprocessors are clearly elaborations of this early 
system. 

The idea of a compiler had begun to develop and 
several “compilers" existed [6]. The programmer could 
write pseudo-codes to refer to subroutines, and the 
compiler performed the combining function envisioned 
by von Neumann. The function of a compiler was to 
interpret the pseudo-code, look up the subroutines in the 
library, then adjust and assemble them into a complete 
536 program. Although there is a vague resemblence between 
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these early compilers and modem compilers, the stracSL 
ture and tasks of modem compilers had not yet emerged.' . j 

• Early IBM assemblers 

The first symbolic assembly program produced by IBM 
was the NR9003 (described but not identified in [7]) for, . 
the 701. It was developed by the 701 engineering manag- 
er, N. Rochester, so that the engineers could test the 
machine. It made program modification easy by using i; 
symbolic addresses and by permitting the assembly of 
separately written programs. Different names for the 
same location could be associated by the use of a SYN- 
onym pseudo-operation. Thus aliasing, the bane of com- 
piler writers, made an early— albeit necessary— appear-' 
ance. 




The most widely used IBM assembly program for the 
701 was the IBM S02 [8] written by William McClelland.- ' 
This assembler supported relative addresses from an ; 
origin and performed extensive error checking. Hardwares! 
errors were frequent and often undetected by the hard- 
ware, so checking methods and restart procedures were 
important design criteria in early systems. 

The concept of “regional programming" [8, 9] was 
used to effect program relocation: Storage was divided^ 
into regions into which the various programs, data, and, | 
in at least one version of the idea [10, 11], dynamically 
overlaid, temporary storage for subroutines could be ' ^ j 
placed. This latter usage was very close to today’s use ofe 
dynamic, stacked storage areas by procedures in such$ 
languages as pl/1. The implementation techniques were y! 
necessarily quite different since the 701 did not hayeg 
index registers. 

• Early higher-level language processors 
IBM’s first higher-level language was Speedcode * 

[I, 12, 13] developed by John Backus in 1953 for the 701-.^ 

He stated [12] that the . . most important reason for 
having a Speedcoding calculator, in addition to the 701, isj 
a matter of economy . . . . Programming and testing costs 
often comprise between 50 and 70% of the total cost < 
operating a computing installation. . . . Speedcoding l 
duces coding and testing time considerably." The systeq 
was an interpreter which caused the 701 to behave like i 
three-address, floating-point calculator. Although it 
quired over 30% of the memory (310 words), it support© 
an extensive repertoire of mathematical, I/O, and cheeky 
ing functions which were compactly expressed. 

Indeed memory space, both primary and secondary 
was a very scarce resource and strongly influenced thej 
design of language processing systems for many years.'; 
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A compiling system, PACT I [14-20] for the 701 (and 
PACT I A [21] for the 704), emphasizing storage optimiza- 
tion. was started in late 1954 by a committee of IBM 
empl°yees and customers. The compiler automatically 
allocated primary storage in regions for programs and 
data. In addition to space for the user’s scalars, vectors, 
and arrays, special regions existed for temporaries and 
for the “perishable" data used by library routines. It was 
noted [19] that a compiler might be able to make an 
optimum automatic storage allocation but it would re- 
quire that the compiler “follow the logic of the entire 
program." Steel noted [21] that . . logically it has a 
good deal of similarity to the celebrated ‘four color’ 
problem.” With the exception of work by Ershov [22], 
these ideas were not fully explored until very recently 
[23, 24]. It is interesting to note that the compiler used a 
technique when constructing and accessing the table of 
variables which has since become known as hashing. This 
technique, in almost exactly the same form, is used 
commonly today. Knuth [25] cites H. P. Luhn with 
originating hashing and describing it in an IBM memoran- 
dum written in 1953. At about the same time another 
group of IBM people, Gene Amdahl, Elaine Boehm, 
Nathaniel Rochester, and Arthur Samuel, independently 
developed hashing for use in an assembly program they 
were writing for the 701. In 1979 a nice theoretical result 
[26] was obtained by J. L. Carter and M. Wegman which 
guarantees a good expected performance for any set of 
variables. It will undoubtedly become the standard hash- 
ing method used in future compilers. 

• SOAP: an optimizing assembler 
One of the earliest IBM systems to feature optimization 
was SOAP (Symbolic Optimizer and Assembly Program) 
for the IBM 650. By storing data and instructions on the 
650 drum so that the drum was in the right position when 
data or the next instruction was required, a program 
might run as much as six or seven times faster [27]. While 
automatic optimization did not achieve such dramatic 
improvements, a factor of as much as 3.8 was obtained by 
a simple, two-pass preprocessor [28]. In designing this 
preprocessor, a predecessor of SOAP, optimum was 
taken as the point at which the improvement-per-unit- 
effort is maximized. The study of program optimization 
has continued to emphasize the development of faster 
techniques for improving the execution time of a pro- 
gram. 

Most programs at the beginning of this early period 
were written in machine language. By the end of the 
period several automatic programming systems existed 
which provided a synthetic “computer” different from 
the real computer. Many of these systems were, howev- 
er, costly to use, either because they were interpreters or 
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because they relied on precoded routines to implement 
functions in the language not directly supported on the 
machine. 

FORTRAN I 

• The project and its context 

Early in 1954 the fortran I project was formed by John 
Backus. A fundamental question posed by the project 
was [29] ”... can a machine translate a sufficiently rich 
mathematical language into a sufficiently economical pro- 
gram at a sufficiently low cost to make the whole affair 
feasible?” A major goal [29] was to provide an automatic 
programming system which "... would produce pro- 
grams almost as efficient as hand coded ones and do so on 
virtually every job.” This seemingly impossible goal was 
met to an astonishing degree. In some cases it produced 
code which was so good that users thought it was wrong 
since it bore no obvious relationship to the source. It set a 
standard for object program efficiency which has rarely 
been equaled. The fortran i compiler, begun in 1954 and 
completed in 1957, established modern compiler tasks, 
structure, and techniques. Indeed some of the techniques 
are still used in nearly the same form. 

The compiler was developed for the 704, an IBM 
machine introduced in 1954 featuring built-in floating 
point and indexing capabilities. It compiled the fortran I 
language which was defined as part of the project and 
evolved considerably as the project progressed. In order 
to achieve its efficiency goals, the high level arithmetic 
statements in the source program had to be translated so 
as to minimize storage references and, even more impor- 
tantly, subscripts and their control had to make maximal 
use of the machine’s three index registers. How all of this 
was achieved is described in [30], formalized in [31], and 
reviewed in [32] and [29]. This latter paper in particular 
contains a penetrating analysis of the project its origins, 
development, and impacts — and should be read by every- 
one interested in computer science history or in compil- 
ers. i 

• The overall organization of the compiler 

The compiler was divided into five sections (phases in 

today’s terminology): 

i 

1 . A statement identifier and arithmetic statement trans- 
lator, 

2. A subscript and DO statement analyzer, 

3. A transformer which interfaced sections 2 and 4, 

4. A control flow analyzer, 

5. A global register allocator, and 

6. Final assembly. 

We now discuss sections 1, 2, 4, and 5 in more detail. 
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Translation 

Today's compilers often use elegant, language-indepen- 
dent translator systems. The theory behind these systems 
did not really start to develop until the 1960s, but the 
problem appeared in its full form in this system. Given an 
arithmetic expression, the translator first created a se- 
quence of arithmetic instructions, then transformed this 
sequence to eliminate redundant computations arising 
from the existence of common subexpressions (their 
term) and to reduce the number of accesses to memory. 
These transformations have been the subject of numerous 
investigations ([33] contains a good set of references), and 
we now know that an optimal solution is inherently hard. 

Subscript ami DO statement optimization 
The translator did not complete the translation of DO 
statements and subscripts — that was the function of sec- 
tion 2. designed and developed by R. A. Nelson and I. 
Ziller. A symbolic index register corresponding to each 
particular subscript combination of a variable was created 
by the translator and existed until section 5 had assigned 
registers. The function of section 2 was to optimize the 
calculation of subscripts and do control statements. The 
constant parts of the calculation were incorporated into 
operand addresses; operations involving do control varia- 
bles were transformed into index register increments 
when possible; loop-independent parts of the calculation 
were removed from the loop; and the loop exit test was 
transformed to use one of the registers needed for index- 
ing. A nest of do loops for array calculations was 
sometimes replaced by a single loop in the generated 
code! Some of these transformations are now subsumed 
in a somewhat more general optimization called "strength 
reduction" [34], but. with one possible exception [35], 
today's production compilers do not generally do as well. 

Flow analysis 

The function of sections 4 and 5 of the compiler was to 
assign real registers to the symbolic registers. Except for 
the symbolic registers and the assumption that they could 
all be assigned to real registers, the program on entry to 
section 4 was complete. The basic task, therefore, was to 
assign the symbolic registers to real registers so as to 
minimize the time spent loading and storing index regis- 
ters. Section 4 of the compiler did a flow analysis of the 
program to determine the pattern and frequency of flow 
for use in section 5 where the actual assignment was 
made. 

Basic blocks ("a basic block is a stretch of program 
which has a single entry point and a single exit point" 
[30]) were found and a table of immediate predecessor 
blocks constructed. Here, then, is the beginning of the 
elegant and fast control flow algorithms of today. Basic 


blocks and predecessor (successor) relationships are in- } 
puts to these algorithms. 

The other task performed by section 4 was the compui' . 
tation of a probable frequency of execution of every 
predecessor edge. To do this Lois Haibt developed a ; 
Monte Carlo "execution" of the program with initial 
weights assigned to each edge. This method is no longer " 
commonly used to identify frequently executed areas of a 
program; rather the program topology is used more; 
directly but with less resultant precision. 

Register assignment 

Using the edge execution frequencies, regions were ' 
formed so that registers could be assigned to the most 
frequently executed areas (usually innermost loops), then' 
to the next most frequently executed areas, etc., until the 
entire program had been treated. When a region had been 
processed, its entry and exit conditions were recorded: ;v 
the values to be loaded on entry and stored on exit. A 
processed region was not re-examined when its contain-!; v 
ing region was processed, but the entry and exit condj-' 
tions and whether or not it had any unassigned registers 
were used. The assignment of registers within a basic:®!; 
block used a "distance to next use" criterion to deter-gs 
mine which register to displace when out of registers.;/^ 
"Activity bits” were used to determine the necessity of 
storing a value in a register for subsequent use if the 
register had to be reused. In case of register assignment;# 
mismatches across basic blocks, an attempt was made to; - 
permute the assignment. 

' 

This register assignment method, developed by Shel-jT 
don Best, was a phenomenal piece of work. The displace-,]^ 
ment algorithm for straight-line code was later proved 
optimal [36] for the "one-cost model" [37]; A displace-. ; 
ment costs the same whether you need to store the,*., 
register contents or not. Until 1980. when Gregory Chai- 
tin [23] successfully applied a graph coloring algorithm '7 
to the global assignment of registers, most global assign- 
ment methods [38-40] were essentially variants on the .v, 
fortran I approach. 

‘‘ '^9 

• An assessment 

Perhaps the best way of demonstrating the results of this -y. 
project is to show an example of its output— an output. 
which startled this author. The fortran program in FigT isj 
1 moves array B to array A. The assembly program shows * 
this being done with one loop instead of the two expected^® 
from the source, (fortran stored its arrays column-wise’;^ 
and backwards; the 704 subtracted the value in the indexjfe 
register from the address.) jtflB 

The real results of the project are the influences it had ja 
on future compilers and theory. Some of these effects?.® 


have already been mentioned; more will be discussed 
later . Suffice it to say that the technological fallout from 
this project has been extensive. 

The late fifties and early sixties 

, Characteristics of the period 

The period from 1957, when the 709 was announced, to 
[964. when System 360 was announced, was one of great 
optimism and little discipline. New languages, comput- 
ers. systems, and ideas appeared at an astonishing rate. 

By 1964 IBM implementations of fortran, Comtran, 
cobol. rpg. Autocoder, print, formac, gpss, and other 
languages existed on at least one of the computers 
introduced during the period: the 709-90 , 707-70, 1401, 
1410-7010. Stretch, 7040-44. and others. Total systems, 
such as IBSYS for the 7090, provided a unified execution 
environment and a central set of facilities to exploit the 
capabilities of such hardware features as buffered I/O. 
Time-sharing systems, such as Quiktran, provided on- 
line, interactive facilities. Formalisms emerged, and the 
understanding and use of fundamental data structures 
such as lists and trees became widespread. However, the 
spirit of the period is probably best exemplified by the 
interest in universal compiling systems. The obvious 
problem created by the proliferation of languages and 
computers led to numerous efforts to provide a single 
system capable of compiling multiple source languages 
for multiple target machines. 

• Some interesting systems 

Language processors for the 709, 7090-94 systems 
The first system designed for the 709, 7090-94 computers 
was SOS or SCAT (SHARE Compiler Assembler Trans- 
lator) [41-46]. It was a very complex system designed by 
a committee spread throughout the country and repre- 
senting many different companies. It was to provide 
source-level debugging without the cost of complete 
retranslation whenever the program changed or addition- 
al information was needed. The central mechanism was a 
■'SQUOZE” form of programs arising from the partial 
translation of various source inputs, including incremen- 
tal changes from the user. It never became a production 
system. It was late, the general quality was poor, and 
there were serious performance problems in "loading 
multiple modules of SQUOZE decks. Furthermore, there 
was a reluctance to change from the existing patterns of 
program development and execution. 

Concern for the compile-time cost of translating pro- 
grams did not, however, disappear. In fact the original 
fortran I system had already been modified to handle 


DIMENSION A( 10,10) 
DIMENSION B( 10, 10) 


DO 1 J=l,10 
DO 1 1=1,10 
1 A(I, J)=B(I, J) 


RESULT 


LXD ONE, 1 
LOOP CLA B-F 1,1 
STO A+I.l 
TXI *+1,1,1 


load 1 into regl 


TXI *+1,1.1 add 1 to regl and 
goto next inst 

TXL LOOP, 1,100 if regl ^100 
goto loop 

ONE ,,1 data value one 

A BES 100 reserve 100 Iocs, 

ending with A 

BES 100 reserve 100 Iocs, 

ending with B 


Figure 1 FORTRAN I translation of array move. 


fortran II — a language featuring subroutines and COM- 
MON blocks of shared variables. These extensions to- 
gether with the BSS loader were a significant factor in the 
acceptance and effective use of fortran for large pro- 
gramming applications. Assembly language programs and 
separately compiled programs could be loaded and exe- 
cuted as a unit. 

In 1961 a decision was made to completely rewrite the 
fortran compiler to improve the compile speed and to 
support the new fortran IV language. Another factor in 
the rewrite decision was the new, integrated system, 
IBSYS, for the 7090: The new fortran would be an 
integrated component. The new compiler [47] was neither 
very fast nor did it produce object code as efficient as the 
original compiler. The new compiler did, however, intro- 
duce a new transformation: "anchor pointing” to opti- 
mize fortran iv’s logical expressions. The evaluation 
order of the components of a logical expression was 
revised to minimize the time required for evaluation. 

/ 

The Comtran and COBOL compilers 

A compiler for Comtran (Commercial Translator), an 
early IBM language supplanted by COBOL, was delivered 
in early 1961. The Comtran compiler contained a number 
of new and very innovative techniques. Unfortunately, 
they were never published. The project manager, Richard 
Talmadge, invented a table driven scanner (probably the 
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first) and extended the PACT IV hashing methods for use 
in this system. Robert Rock developed a nice method for 
handling n-tuples. Much of the system design was used in 
the 7090 coboi., where it was augmented by a very early 
table management system. CITRUS, written by Claude 
Coray. 


The scanner used an operator precedence table with a 
mechanism for handling parentheses and varying num- 
bers of operands. As the input string was scanned, a table 
of operators was built giving the precedence and position 
of each. This table was then sorted by precedence value 
and used to generate /t-tuples trom the text string. Each 
unique /.-tuple was assigned a unique symbolic register to 
hold the result, and the text string was dynamically 
modified (reduced) to the symbolic register replacing the 
operator and operands. Before assigning a symbolic regis- 
ter to an /.-tuple, a search was made to determine if it had 
occurred previously in the statement. If it had. the /.-tuple 
was not put out-a common subexpression had been 
found. On completion of the scan of a statement the 
number of symbolic registers used in the output was 
minimized. 


The scanner was driven by a table containing a set of 
syntax vectors. Each vector contained an encoded ques- 
tion related to the scan stale and two branch target 
locations: one if the answer was true, the other .f false. 
An interpreter used the table to determine the routing to 
the target action routines. 

The dictionary organization was strikingly similar to a 
form commonly used today. The source program names 
were stored in a symbolic dictionary, attributes in an 
attribute table. These tables were packed, and hashing 
through a sparse intermediate table was used to look up 
names. 

These techniques were carried over to the COBOL 
compiler developed for 1BSYS [48], In addition to incor- 
porating these early and excellent techniques, the 7090 
COBOL compiler was also one of the first systems [49] to 
use a dynamic table management and spill system. CIT- 
RUS (for Coalesced Indirect Table Reference Unification 
Scheme). The compiler's tables could be opened, closed, 
relocated, expanded, and contracted during execution. 

FORTRAN for the 1401 

The 1401, announced in 1959, was a small, character- 
oriented computer imposing a severe set of constraints on 
the fortran compiler design [50]. It was designed to 
operate in 8000 storage locations (characters) with tape 
usage being optional. We mention the fortran compiler 
for the 1401 in this history because it exemplifies an 



interesting design for a small system. The compiler con- - 
sisted of 64 phases, the first three of which were loaded® 
before the program. The entire program was then read in, 't 
and the remainder of the compiler was passed against the 
program, one phase at a time. When the compiler was gj 
finished, the program was in executable form in memory . .. 
and could be executed immediately. An object deck was <), 
optionally available. While the system did not permit 
arbitrarily large programs, it made very effective use of , /; 
the space available and did not incur the overhead.® 
associated with storing intermediate results on tape. ’ " 1 

Quiktran 

In 1963, Quiktran, IBM's first time-sharing system, was 
operational [51,52], Developed by J. Morrissey, Tj| 
Dunn, J. Keller (Rivlin). E. Strum, and G. Yang, it 
supported 40 concurrent users on the 7040-44 computers ^ 
with a fortran interpretive system providing interac- ;-' 
tive. source-language-level debugging. The system could 
act as a desk calculator and could dynamically alter the ; 
program during execution. Each executable statement 'jgf 
was stored internally as a polish string created by using a 
bi-directional "forcing table," which was also used to/?*/ 
recreate the source. Because of this capability and be-/.r 
cause the language was standard fortran, a program, 
could be debugged using this system, then recreated for 
compilation by a standard FORTRAN compiler. The PL/I 
Checker [53], currently available for debugging PUl pro- 
grams, provides many of these same facilities but does / 
not recreate the source from the internal form used by the 
interpreter. 

The Stretch-Harvest compiler 

An early and persistent goal of compiler designers has ^ 
been the construction of a single compiler for multiple eg 
source languages and multiple target machines. The com- 
piler for the Stretch-Harvest computers compiled FOR- 5* 
tran and Alpha language programs and was designed to .t, 
handle other languages as well. The two source languages \,,, 
were as dissimilar as fortran and COBOL, and the || 
Harvest attachment to Stretch bore no resemblance to its j " 
host. One of the central notions in the design of many ; 
such systems is that a common internal (intermediate) . 
language (IL) can be found for expressing all the source J 
languages. Ideally this common IL is such that very little V 
language-specific code is needed in the system. In the , 
Stretch-Harvest compiler the common IL was a high level v 
Autocoder to which each source language could be traits-, 
lated by one pass. 

Having translated the source to IL, the second phase of o 
the compiler made three passes over the program to map - 
storage and expand subscripts, to collect flow and sym-T 
bolic register-usage patterns, and to assign index regis-T 
ters. The second phase produced macros for input to a; 
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subsequent macro-assembler. A variant of an early list 
processing system [54] developed by H. Gelernter, J. 
Hansen, and C. Gerberich was used in phase 2 to manage 
the internal data structures. 

The system was not a success; compilation time was 
unacceptable. The interfaces between phases were in 
externally readable form, costly to construct and costly to 
read and write; either language, and fortran in particu- 
lar could have been compiled much more efficiently by a 
language-specific system. Compiler technology, and the 
art of effectively utilizing it. was not advanced enough in 
I960 for such a system. 

• Universal compiling systems 

The Stretch-Harvest compiler design was, however, con- 
servative when compared with proposals for some other 
language processing systems. Motivated by the prolifera- 
tion of languages and computers and by the continued 
scarcity of skilled programmers, particularly experienced 
compiler designers, the idea of a universal compiling 
system became very popular. In the late 1950s there was 
considerable interest in the design of an UNCOL (UNi- 
versal Computer Oriented Language) [55] to which any 
high level language could be translated and from which 
executable programs could be created for any machine. A 
new language would require a new translator to UNCOL, 
and then compilers for that language would exist on all 
supported computers. Similarly a new computer required 
one translator from UNCOL to get a family of compilers. 
Though investigators soon despaired of finding such a 
language, the motivating factors still existed. 

Within IBM there were two universal compiling sys- 
tems projects in the early 1960s: xtran [56] and slang 
[57], Julian Green's xtran approach was to provide a 
boot-strapped, list-processing system which transformed 
the source string to the object string. It used auxiliary 
information about source symbols and operators to trans- 
late the source language to a macro language, then used 
macro definitions to translate the macro language to 
machine language , and finally optimization information to 
optimize the machine language. This approach was in- 
tended to minimize the consequences of changes to the 
processor algorithm, the source language, or the object 
language. In 1962 a decision was made to terminate the 
xtran project and concentrate on the much more ambi 
tious slang (Systems Language) project being developed 
by R. Sibley. 

slang was both a problem-oriented, machine-indepen- 
dent language and a compiler with a machine description 
capability. The main emphasis in its initial formulation 
was to achieve machine independence, thereby providing 
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portability of compilers written in SLANG and, since the 
SLANG compiler was written in SLANG, of the slang 
system itself. As the system developed, a syntax-directed 
facility was added to provide source language indepen- 
dence through the use of an augmented BNF (Backus 
Normal Form) [58] description of the source language 
being compiled. The source language description was 
compiled and used to translate the input program to 
EMILs— Elementary Machine Intermediate Language 
statements. Tables defining the target machine character- 
istics were then used to translate EMILs to object code. 

The slang project was terminated in 1965 when it 
became apparent that the object code produced, and 
hence the slang system and all compilers written in it, 
was too inefficient. Machine independence failed for 
several reasons: there was no adequate way to parameter- 
ize the description of the machine-particularly its I/O; 
when writing a program in slang, users generally opti- 
mized it for a particular machine; and the effect of storage 
size on the overall organization of a compiler could not be 
described. Language independence failed due to the lack 
of a satisfactory method of semantics specification and 
because the parameterization was done with respect to 
existing languages (fortran and COBOL). Any language 
with new or extended features became a problem to 
describe. In particular the new language, PL/I, was too 
difficult for SLANG. 


It is now generally accepted that a special compiler- 
writing language is not necessary, but if the goal is a 
reasonably efficient compiler written in its own language, 
it is essential that that compiler be capable of producing 
good code. Techniques for providing both a machine 
descriptive capability and producing good code are only 
now beginning to emerge. 

• Early developments in the theory of parsing 
Program translators today usually use a lexical analyzer 
(scanner) and a syntax analyzer (parser) to recognize the 
substrings in the source string. Lexical analyzers recog- 
nize the tokens (operators, separators, identifiers, etc.) 
using transition diagramed finite state automata. Syn- 
tax analyzers recognize the substrings (phrases) using a 
context-free grammar. In fact efficient parsers can be 
automatically constructed from a grammar. Many of 
these elegant systems have their roots in the practical and 
theoretical efforts of this period. 

The syntactic notation BNF, commonly used to specify 
a grammar, was introduced by John Backus in 1959 [58]. 
It is discussed elsewhere in this issue. 

A major contribution to the theory of parsing was made 
by John Cocke. Though not fully documented at the tune, 
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il was mentioned in [59], and a variant, the nodal span- 
ning parse, appeared in 1969 [60], An excellent discussion 
of the relevance of Cocke's parsing method was given by 
Robert Floyd in his 1978 Turing Award Lecture [61] and 
is quoted in the next paragraph. 

"In the early 1960's, parsing of context-free languages 
was a problem of pressing importance in both compiler 
development and natural linguistics. Published algorithms 
were usually both slow and incorrect. John Cocke, alleg- 
edly with very little effort, found a fast and simple 
algorithm [62], based on a now standard paradigm which 
is the computational form of dynamic programming [63]. 
The dynamic programming paradigm solves a problem for 
given input hy lirst iteratively solving it for all smaller 
inputs. Cocke's algorithm successively found all parsings 
of all substrings of the input. In this conceptual frame, the 
problem became nearly trivial. The resulting algorithm 
was the first to uniformly run in polynomial time." 

The mid- and late sixties 

• Characteristics 

On April 7. 1964, IBM announced the System/360. The 
announcement included live basic, compatible computer 
models with 19 combinations of speed and storage capaci- 
ty: the largest processor was 100 times more powerful 
than the smallest, and the main storage capacity ranged 
from 8192 bytes to more than eight million. The system 
was supported by a powerful operating system incorpo- 
rating several data base access methods and interfaces to 
numerous auxiliary storage and input-output devices. 

Language processors for FORTRAN. COBOL, the new put 
language, and other languages had to support most of the 
configurations and to function in the environment sup- 
plied by the operating system. These requirements, to- 
gether with the fact that many design decisions were 
being made in parallel, created a rather formidable chal- 
lenge for the designers of these systems. Several "design 
points" determined by the maximum memory size avail- 
able to a system were established to cope with the 
memory constraints. Families of upwards-compatible lan- 
guage processors were then produced. For example, 
three distinct fortran compilers were written for use 
with the main operating system OS: an E level requiring 
32 000 bytes, a G requiring 128 000, and an H requiring 
256 000. 

Most of the language processor efforts during this 
period can be characterized as the engineering of existing 
technologies to fit the constraints, fortran h was an 
exception. We now discuss that work and some other 
technological and scientific advances which appeared in 
the late 1960s. 


C. W. Medlock and E. Lowry, designers of the Fortran'^ 
h optimizer, stated [38] that: "For small loops of a few " 
statements (the fortran h compiler) very often produces im- 


perfect code." This was accomplished by global (to a g 
subroutine) optimizations which generalized and thus '? 
extended the transformations used in earlier fortran f- 
compilers. particularly fortran l. Control flow analysis ‘y 
of the program was based, as in FORTRAN I, on a control ' 
How graph in which the nodes represented basic blocks. 
Loops arising from constructs other than DOS were recog- 
nized. and "back dominators" were found. A back 
dominator of a node represents code which has to be 
executed before code in the node of interest is executed, 
and thus is a natural place to look for common subexpres-'?' 
sions and to place code when the back dominator is less 
frequently executed. All subexpressions, not just those 
related to address calculations arising from subscript Ty; 
expansions, were considered— one subexpression at a 
time. Advances in the technology since that time permit f. 
the identification of all formally identical common subex-^fj 
pressions in parallel. Numerous other transformations';/.-- 
and analyses, including a limited form of data flow A'/ 

’ 3B V. 

analysis, were incorporated. 

m 

The efficacy of these optimizations is demonstrated by 
the fact that fifteen years after its release, it is still one ofjSg 
the best product-compilers in terms of object code effi- 2 .^ 
ciency. (Some improvements have been made by R. G. 
Scarborough, primarily in the area of subscript expan-*i& 
sions and register allocation [35].) The design was incor-;^; 
porated into an optimizing compiler for pl/i (pliopt) and‘jjg|* 
also proved adequate for supporting the fortran compilr^S 
cr itself, 70CT of which was written in fortran. 


Although the initial plans for implementing the newly, dg 
defined pli language for System 360 included a family of || 
compilers, only two, PL/l F and pm d, were produced. As ^ 


it was, this was a monumental effort requiring great ^ 
ingenuity: The language was large, the design point small, 
the operating system interactions extensive. The impIe-^K 
mentation of the new and comprehensive facilities for -jar', 
storage management, interrupt handling, and multitasking -Jj 
were particularly innovative. J. Cox, J. Nash, and 
Clarke were most responsible for pulling off the enormous 
engineering effort which at its peak involved some 70.J& 
people. 

Subsequent to the release of the PM F compiler, a;.| 
technique for optimizing pm was investigated [64] by M.JjJ 
Elson, R. Lamer, S. Rake, and others. The thesis of the|||£ 
investigation was that context sensitive (“special cas-\S 
ing“) code generation techniques were needed to produce Jap 


mm 
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good code for a language as rich as pl/i on a machine such 
as the 360 with its multiplicity of possible code sequences 
for even the simplest of functions. The form of the 
investigation was to produce a prototype system in which 
each statement was stored as a tree augmented with the 
data attributes, and a tree-walking, interpretive subsys- 
tem was used to generate code. Although this investiga- 
tion did not directly result in a product, the thesis has 
remained attractive. The problem with it is the size of the 
code generators and the consequent probability of errors. 
Furthermore, it cannot deal effectively with transforma- 
tions requiring more global information, such as register 
assignment across loops. A recent system, based on a 
diametrically opposite thesis, is discussed later. 

• APL 

Interpreting code is often at least an order of magnitude 
slower than executing it directly. The apl system is a 
counter example. L. Breed and R. Lathwell, who, togeth- 
er with Roger Moore, built the system, state [65] that: 
"The apl processor is interpretive: however, because of 
the efficiencies afforded by array operations, program 
execution is often one-tenth to one-fifth as fast as com- 
piled code.” Another factor is the excellence of the 
design. The system, initially implemented on the 7090 and 
then, in 1966, on the 360, consisted of a supervisor and 
the interpreter. It was designed as a total system in which 
the supervisor had complete control over system re- 
sources and the supervisor-interpreter communications 
could be simplified. The anticipated use of the system and 
the language constructs were carefully considered when 
making design choices. An interesting evaluation of these 
choices and the historical setting in which they were 
made is given in [66]. 

• The ACS project 

The Advanced Computing Systems (ACS) project was a 
hardware-software project started in 1964 as System Y at 
the IBM Thomas J. Watson Research Center. The aim of 
the project was the design of a very high performance 
system for the large scientific market. From the beginning 
of the project it was recognized that the only way to 
realistically realize the performance goals and make them 
accessible to the user was to design the compiler and the 
computer at the same time. In this way features would not 
be put in the hardware which the software could not use 
or which the software could support more effectively. 
The CPU, for example, had a high degree of parallelism, 
both in fetching instructions and data and in instruction 
execution. Could the compiler schedule the instruction 
stream to take advantage of the parallelism? It turned out 
in fact that the experimental optimizing compiler devel- 
oped to evaluate CPU designs could sometimes do better 
than carefully hand-optimized code. 


In order to isolate the effects of changes in the CPU 
design and to modularize the experiment, the ACS com- 
piler classified the optimizations as machine independent 
or machine dependent. The machine independent analy- 
ses and optimizations [67] included a general control flow 
analyzer, common subexpression elimination and code 
motion, data flow analysis, strength reduction, constant 
propagation, and dead code elimination; the machine 
dependent transformations included scheduling [68] and 
register allocation [39, 69]. With the exception of sched- 
uling, most of the other analyses and transformations had 
appeared in previous IBM compilers, particularly for- 
tran I and fortran H. In the ACS compiler (which, like 
the entire ACS system, never became a product) the 
techniques were generalized and isolated as much as 
possible from source and machine language constructs. 
This is an essential step, of course, in the evolution of 
general compiler building tools. Out of this project came, 
therefore, numerous advances in compiler technology 
and, more importantly, the foundations of the theory of 
program analysis and optimization. The elaboration and 
refinement of this theory was the major development in 
language processor technology during the next decade. 

Recent history: the seventies 

• Characteristics 

Increasing maturity is perhaps the hallmark of computer 
science and technology in the 1970s. The cycle from 
pragmatic problem (with a heuristic solution) to formal 
solution to realization of the solution in a practical system 
has been completed, or at least well started in numerous 
cases. The study of algorithms has led to a growing 
collection of tools whose time and space bounds and 
correctness are known. Programming has become more 
disciplined, and formal mechanisms for describing and 
verifying various properties of systems have been exten- 
sively investigated. 

Language processor technology has been both the chief 
benefactor and the raison d'etre for much of the work. 
Parsing and program optimization are the quintessential 
examples of the evolution of the technology. 






At the beginning of this decade, the theory of parsing 
was well understood; by the end of the decade, a fast, 
reliable parsing system is one of the on-the-shelf tools 
a programmer uses when building a compiler. At the 
beginning of the decade, the theory of program analysis 
and optimization was in its infancy; now some of the 
results of these investigations are appearing in various 
implementations. Register allocation is another area in 
which both theoretical and practical advances have been - 
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made. In this section we trace the evolution of these latter 
technologies and briefly describe one implementation 
utilizing them. 

• Program analysis and optimization 
In 1970 two papers [70. 71] described fast, abstract meth- 
ods for program control and data flow analysis. Given a 
directed graph representation of a program, one paper 
[70] showed how the graph could be partitioned into 
“intervals” (single entry subgraphs in which all loops 
contain the entry node) and. treating each interval as a 
node, higher order graphs were derived and then ana- 
lyzed to effectively codify the nesting structure of the 
program. The algorithm was abstract in that it did not 
depend on specific source language constructs, such as 
Dos. and it was fast when applied to typical program 
graphs, though it had a poor worst-case bound. For each 
graph it was linear in the number of edges, and, since the 
number of derived graphs rarely exceeds three in practice 
(the depth of nesting of loops), the number of derived 
graphs was small. Since that time a nearly linear algo- 
rithm has been found [72] which also gives a somewhat 
better codification of interesting control flow relation- 
ships. However, the most important feature of the inter- 
val analysis method was that a node ordering was estab- 
lished which could be used to rapidly determine other 
relationships in the program. 

The second paper [71 ] dealt with a particularly interest- 
ing application: common subexpression elimination and 
code motion. All redundant, formally identical (look- 
alike) subexpressions in the entire program could be 
identified by one execution of a fast algorithm— having 
the same time bound as the interval analyzer. The algo- 
rithm not only recognized subexpressions which could be 
eliminated from the program when the computation al- 
ready existed on all paths to the subexpression, but it also 
found code which could be moved out of a loop or nests 
of loops. 

Another important application was finding “def-use” 
relationships: Given a definition of a variable, all poten- 
tial uses of that definition are of interest during optimiza- 
tion and register allocation. The relationship and its dual, 
the use-def relationship, are needed for strength reduc- 
tion [34], constant propagation, dead code elimination, 
and other transformations [73]. The interval-based algo- 
rithm [74] for finding all such relationships was fast in the 
sense described previously; now nearly linear algorithms 
[75] exist. 

A natural consequence of the existence of fast analysis 
and optimization algorithms for individual procedures, as 
well as the development and maintenance of on-line 


program data bases and advances in programming meth- 
odologies, was an interest in analyzing and transforming 
collections of procedures. The first investigations [76, 77] 
into interprocedural analysis defined the problem and 
outlined pragmatic solutions. Elegant, though not neces- 
sarily pragmatic or completely general, algorithms [78— 
80] now exist. A research project, the Experimental 
Compiling System [81-83], is investigating the use of 
interprocedural analysis [83. 84] and optimization in a 
compiler building system. The basic ideas are to use 
procedures to express the semantics of the language being 
compiled, to deduce the characteristics of the language by 
analysis, to use procedure integration (in-line expansion) 
to do code generation, and to optimize in order to 
customize and obtain good code. 


The work on program analysis and optimization has 
many parallels with the work on parsing and will undoubt- . 
edly prove to be as important. It seems almost certain 
that language-independent tools for analyzing and opti- 
mizing programs will become as available as lexical 
analyzers and parser-generators are now. Also, just as 
our understanding of parsing has affected language de- 
sign, so will our understanding of optimization. It seems 
unlikely that new languages will continue to contain 
constructs such as unconstrained aliasing which con- 
found analyses (as well as users). 


• Global register allocation 

One of the very difficult functions of an optimizing 
compiler is register allocation. It has been formulated as 
an integer programming problem [85] and shown to be a 
hard problem [86] even for straight-line code. Practical 
implementations are necessarily heuristic and typically 
complex. Recently a fast (usually) and surprisingly good 
(approaching that of hand-coded assembly language) ap- 
proach has been developed and implemented [23] by G. 
Chaitin. The problem is formulated as a graph coloring 
problem: Each node in the graph stands for a computed 
quantity that resides in a machine register, and two nodes 
are connected by an edge if the quantities interfere with 
each other, that is, if they are simultaneously live at some 
point in the object program. The problem is to assign 
different colors (registers) to connected nodes. Obtaining 
an optimum coloring is hard, but the implementation 
showed that a fast heuristic method for assigning colors to 
these particular graphs generally resulted in a very good 
assignment. Another interesting aspect of the work was 
that most of the idiosyncrasies of the target machine 
( e.g . , register pairs, dedicated registers) could be handled 
uniformly and systematically. It seems likely that this 
approach to register allocation will be the basis for many 
interesting investigations and elegant implementations. 
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• An implementation 

In our discussion of pizi implementations in the preceding 
section, we said that context-sensitive (special casing) 
code generation was often thought necessary to obtain 
,»ood code for complex languages. In an experimental 
compiler [87] for a variant of PUI a different approach was 
used. Code is produced when some grammatical con- 
struct is recognized by a LALR (Look Ahead Linear 
Right)-produced parser-generator and is not, therefore, 
selected because of its context. This simple and straight- 
forward code is then optimized by a series of stand-alone 
programs implementing the mathematically based algo- 
rithms mentioned earlier. Code selection tricks are avoid- 
ed. Registers are then assigned by graph coloring. The 
method, which is largely language and machine indepen- 
dent, can result in final code approaching and even 
surpassing hand-coded assembly-language programs. 
This result by itself is not surprising— the fortran 1 
compiler accomplished the same thing; its importance lies 
in the means by which it was obtained. 

The uniform, systematic use of mathematically based, 
general algorithms in a compiling system leads to a 
simpler, more predictable design and a more maintainable 
implementation. This is widely accepted. What we now 
know is that this method can also produce better code. 

Summary 

We have traced the history of language processor tech- 
nology in IBM from its rather slow start in 1952 to the 
current collection of elegant algorithms, powerful tech- 
niques, and unsolved problems. General, mathematically 
based algorithms now exist for parsing, analyzing, and 
optimizing programs. IBM has made significant contribu- 
tions to these areas, particularly the last two. The art of 
designing and constructing a language processor system 
has become more scientific and, in some cases, quite 
routine. Assemblers, interpreters, and macro systems are 
generally well understood, though they still require the 
judicious selection of techniques to fit the requirements. 
Though worked on in one form or another for more than 
twenty years, a general production-quality compiler 
building system does not exist. We are, however, much 
closer to this goal: We now have language and machine 
independent translators; recent experiments with similar- 
ly general analyzers, optimizers, and register allocators 
increase the likelihood of such a system being developed. 

A constant motivating force for work in language 
processors has been “the programming problem — ours 
and our customers’. Providing effective systems for lan- 
guages (Speedcode, FORTRAN, and APL are prime exam- 
ples) has permitted and encouraged users to concentrate 
more on problem solving and less on program writing. 


Providing increasingly more general language processor 
tools has permitted the construction of more diverse and 
reliable systems. 

The synergistic relationship between theory and prac- 
tice, noted throughout the paper, leads to two observa- 
tions: All (or nearly all) theoretical results embodied in 
practical implementations concern problems initially 
identified in such implementations; all (or nearly all) 
powerful general tools utilize theoretical results. 

Some final observations 

“Programming is optimization” [88]. Most if not all of the 
choices made in programming a solution to a computable 
problem are aimed at achieving an acceptable level of 
efficiency. For example: How is information to be repre- 
sented? Should it be sorted to permit fast lookups? What 
sort method should be used? These are optimization 
questions, not problem solving questions. If programming 
is to truly become problem solving on a computer, we 
must relieve users of such decisions by providing the 
technology to permit widespread use of very high level, 
problem-oriented languages and tools. In his paper on the 
history of fortran [29], John Backus corroborates this 
view. The next paragraph is from that paper. 

“To this day I believe that our emphasis on object 
program efficiency rather than on language design was 
basically correct. 1 believe that had we failed to produce 
efficient programs, the widespread use of languages like 
fortran would have been seriously delayed. In fact, I 
believe that we are in a similar, but unrecognized, situa- 
tion today: in spite of all the fuss that has been made over 
myriad language details, current conventional languages 
are still very weak programming aids, and far more 
powerful languages would be in use today if anyone had 
found a way to make them run with adequate efficiency. 
In other words, the next revolution in programming will 
take place only when both of the following requirements 
have been met: (a) a new kind of programming language, 
far more powerful than those of today, has been devel- 
oped and (b) a technique has been found for executing its 
programs at not much greater cost than that of today’s 
programs.” / 

I 

1 believe much of the technology is in place to support 
this revolution. The next decade could be very exciting as 
existing technologies are exploited and new ones devel- 
oped to subsume much more of the programmer’s task. 
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P. Lucas 


Formal Semantics of Programming Languages: VDL 


The history of ideas that led to the first formalization of the syntax and semantics of PLU is sketched. The definition 
method and notation are known as the Vienna Definition Language (VDL). The paper examines the relationship between 
VDL and both denotational semantics and the axiomatic approach to programming language definition. 


1. Introduction 

Software, commercial and scientific application programs 
in particular, constitute formidable investments by indus- 
try. High level languages play an important role in the 
protection of these investments by preserving the validity 
and meaning of programs across multifarious hardware, 
operating systems, and implementations, as well as over 
time, as the underlying hardware and systems evolve. 

To remain stable both in form and meaning, a program- 
ming language needs a rigorously precise and implemen- 
tation-independent definition. Such definitions do not 
emerge casually, as committees struggle to standardize a 
language. This has been painfully clear ever since FOR- 
TRAN and ALGOL 60 appeared on the scene. 

The first significant contribution towards rigorous and 
formal language definition was made by John Backus [1] 
for the purpose of defining the syntax of ALGOL 60. The 
method and notation, known as BNF (Backus Naur 
Form), or minor variants thereof, have been used for 
virtually all programming languages since ALGOL 60. It 
enjoys general consensus. The method profoundly influ- 
enced compiler construction and stimulated numerous 
theoretical studies in computer science. 

The success of formal syntax definitions invited similar 
attempts at the formalization of the semantic aspects of 
programming languages, i.e., the definition of the mean- 
ing of programs rather than their form. The problem 
turned out to be obstinate. In spite of considerable 


progress, no satisfactory solution exists, at least none 
that enjoys general acceptance. 

This state of affairs is not particularly surprising. The 
formalization of programming languages inherits a frame 
of reference from linguistics and formal logic [2, 3]; in 
spite of its distinct origin and purpose, the analysis of 
programming languages shares some of the difficulties 
with the analysis of natural languages. 

However, the past two decades have seen considerable 
progress. Language constructs that were only understood 
on an intuitive, pragmatic basis, if at all, can now be 
defined and analyzed in precise mathematical terms. 

The present paper is a retrospective contemplation of a 
piece of work that contributed to this relative success: the 
first complete formalization of the semantics of a com- 
mercially available and generally used programming lan- 
guage, viz., TUI. 

The methodology and the actual definition of PUI were 
developed during the years 1964 to 1969 by the IBM 
Laboratory Vienna under the management of H. 
Zemanek. The definition method and the related notation 
are known collectively as VDL (for Vienna Definition 
Language). The term “Vienna Definition Language,” to 
my knowledge, was first used by J. Lee in [4]. The 
acronym initially used for the PUI formalization was 
“ULD” for Universal Language Document. 


Coovrieht 1981 by International Business Machines Corporation. Copying is permitted without payment of royalty provided diat(l) 
to republish other excerpts should be obtained from the Editor. 


P. LUCAS 



IBM J. RES. DEVELOP. • VOL. 25 • NO. 5 • SEPTEMBER 1981 


